fix: resolve system default input device explicitly for Bluetooth HFP#57
Closed
dmetzler wants to merge 1 commit into
Closed
fix: resolve system default input device explicitly for Bluetooth HFP#57dmetzler wants to merge 1 commit into
dmetzler wants to merge 1 commit into
Conversation
When 'System Default' is selected, AudioEngine now explicitly resolves the default device ID via kAudioHardwarePropertyDefaultInputDevice and sets it on the AudioUnit with AudioUnitSetProperty. This ensures Bluetooth devices (e.g. AirPods) get the A2DP→HFP/SCO profile settling wait and the tap format is built from actual hardware properties rather than AVAudioEngine's potentially stale cache.
Contributor
There was a problem hiding this comment.
Pull request overview
Resolves a macOS audio capture issue where Bluetooth HFP devices (e.g., AirPods) produce no audio when the input device is set to “System Default” by explicitly resolving and configuring the default input device ID.
Changes:
- Resolve “System Default” to a concrete
AudioDeviceIDviakAudioHardwarePropertyDefaultInputDevice. - Route default-device capture through the same per-engine
AudioUnitSetProperty/ Bluetooth HFP settling / tap-format path as explicitly selected devices. - Improve logging to indicate whether the device selection was explicit vs system default.
Comments suppressed due to low confidence (2)
wispr/Services/AudioEngine.swift:112
inputNode.audioUnit!is now executed even whenselectedDeviceIDis nil ("System Default"), becauseresolvedDeviceIDresolves to a real device ID. SinceAVAudioInputNode.audioUnitis optional, this introduces a potential crash if the underlying AudioUnit hasn’t been created yet. Consider safely unwrappinginputNode.audioUnit(and logging / falling back) before callingAudioUnitSetProperty.
var devID = deviceID
let status = AudioUnitSetProperty(
inputNode.audioUnit!,
kAudioOutputUnitProperty_CurrentDevice,
kAudioUnitScope_Global,
wispr/Services/AudioEngine.swift:134
- The Bluetooth HFP settling wait and explicit tap-format construction are currently gated on
status == noErr. IfAudioUnitSetPropertyfails while using the system default device,waitForBluetoothHFP()is skipped again andtapFormatremains nil, which can reintroduce the original “System Default” AirPods failure mode. Consider running the Bluetooth detection / settling wait and buildingtapFormatbased onresolvedDeviceIDeven when the per-engine device assignment fails (or at least for the system-default path).
if status == noErr {
let device = CoreAudioDevice(id: deviceID)
// Bluetooth devices switch from A2DP (48kHz) to HFP/SCO
// (16/24kHz) when the mic is activated. Wait for the rate
// to settle before querying the hardware format.
let isBluetooth = device.transportType == kAudioDeviceTransportTypeBluetooth
|| device.transportType == kAudioDeviceTransportTypeBluetoothLE
if isBluetooth {
try await waitForBluetoothHFP(deviceID: deviceID)
}
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Owner
|
Hey @dmetzler What is the bug this PR fixes ? How can I reproduce the bug to verify this change ?
It works. The Bluetooth HFP bug has been fixed in Is this different ? |
sebsto
added
question
Author
|
So, I was able to reproduce the bug today (2026/05/19) on 1.9.2. I wanted to do a recording using QuickTime. But when I recorded, it finally worked. So there must be something weird in my audio input precedence configuration. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
selectedDeviceIDisnil,startCapture()skipped both the explicitAudioUnitSetPropertycall and thewaitForBluetoothHFP()settling delay — AirPods never switched from A2DP to HFP/SCO mic profilekAudioHardwarePropertyDefaultInputDeviceand route it through the same per-engine device setup path as explicitly-selected devicesWhat changed
AudioEngine.startCapture()now usesselectedDeviceID ?? getDefaultInputDeviceID()so that "System Default" gets:AudioUnitSetPropertyon the AudioUnit (no stale cache)waitForBluetoothHFP()settlingNet diff: +13 / -12 lines in
AudioEngine.swift. No new files, no API changes.